ファイルシステム・インターフェースを用いる、オペレーティング・システムのイベント通知機構のための方法および装置

专利摘要:
ファイルシステム・インターフェースを用いるオペレーティング・システムおよびイベント通知機構のための方法および装置を提供する。一組のイベントをイベント通知のために登録するステップ、各イベントが生じるときにイベント通知を受け取るステップ、および生じたイベントの詳細を得るステップのうちの一つもしくは複数のために各イベント・コンシューマが使用するように設けられた標準ファイルシステム・インターフェースを含む、オペレーティング・システム・イベントを通知するためのシステムおよび構造。
公开号:JP2011511980A
申请号:JP2010544961
申请日:2008-09-10
公开日:2011-04-14
发明作者:ジャン、ジョーフォン；ドゥベイ、ニティーシュ；パットネイク、プラタップ；ラマンジャネア、ブルグラ
申请人:インターナショナル・ビジネス・マシーンズ・コーポレーションＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｓｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ；
IPC主号:G06F11-34

专利说明:

[0001] 本発明は、オペレーティング・システムをモニタリングするシステムに関する。特に、標準のファイルシステム・インターフェースおよびファイル・ツリー表示を用いた疑似ファイルシステムに基づくモニタ機構が、イベント・コンシューマからイベント・リクエストを取り、それらをそのプロデューサに進め、そのイベント・プロデューサからイベント発生情報を受け取り、そしてこの情報をイベント・コンシューマに通知して、定期的なポーリングおよび特化したモニタリングＡＰＩの必要性を除去する。]
背景技術

[0002] 大きなデータセンタのシステム管理者はコンピュータ・サーバー上で集中型モニタリング・アプリケーションとともにランするオペレーティング・システム（ＯＳ）の健全性を一般にはモニタする。そのような集中型モニタリング・アプリケーションはＯＳのインスタンスごとにランするエージェントを一般に有するとともに、ＯＳの健全性関連データを集めるために定期的なポーリングを一般的に行う。このデータはそこで中央のアプリケーションによって、かまたはモニタされるＯＳそれ自体にあって中央のアプリケーションに情報を一般にリレーするエージェントかのいずれかによって分析される。モニタされるＯＳの健全性が悪いことが検出されると、中央のモニタリング・アプリケーションはシステム管理者にイベントを発生する。単純な場合には、このイベントが管理者に通知を送られるようにすることができるし、もっと複雑な場合には（例えば、特定のプログラムの実行など）修正処置を実行することができる。]
[0003] 現在あるＯＳ健全性モニタリング・アプリケーションの定期的なポーリング・アプローチには２つの大きな問題がある。]
[0004] １．ＯＳデータが動的にかつ迅速に変化するので、集められたデータの鮮度または精度、ならびにこの時間センシティブなデータに基づくアクションを取る能力はポーリング期間の長さに依存する。もしその期間（２回の連続するポーリング間の時間）があまりにも長いなら、そのＯＳは一つのポーリング後その後続のポーリングの前に「不健全」状態に入ってしまい、その結果その問題が検出されなくなり、従って修正動作も適時に行われることができない。]
[0005] ２．ポーリング・アクティビティはＯＳにオーバーヘッドを加える。そこでのもっと多くのポーリングしているユーザーがそのＯＳインスタンスにあれば、オーバーヘッドももっと多くなる。]
[0006] 前述の問題に対処するために、幾つかの非ポーリング・イベント通知方法がこれまでも提案されてきたが、それぞれそのアプリケーションが特化されたモニタリングＡＰＩ(Application Programming Interface)を、或るイベントを通知することにその関心があることをレジスタするために、そして或るイベントについてその詳細をそのイベントが生じた後に得るために、使用することを必要とする。]
[0007] 特化されたモニタリングＡＰＩに付随する問題は、言語の結び付きが、大半のシステム管理アプリケーションのために使用される大半の主要な言語のために開発され維持されなければならない。これらの言語のうちで多いのは例えば、Ｐｅｒｌ、Ｃ、Ｃ＋＋、Ｊａｖａ、Ｐｙｔｈｏｎなどである。ＯＳの複数のバージョンにわたって、そして一つのＯＳバージョンの複数の言語にわたって、更に一つのＯＳバージョン内でサポートされる各言語の複数のバージョンにわたって、特化されたＡＰＩを維持しなければならない複雑さというのは、現在あるシステム管理ツールによるこれらの特化されたＡＰＩの使用をしばしば阻む。]
発明が解決しようとする課題

[0008] このように、これらのポーリングおよび特化されたＡＰＩに伴うこれらの問題からみて、オペレーティング・システムの健全性をモニタリングするもっと効果的な方法、好ましくはポーリングを必要とせず、また特化されたＡＰＩを使用しない方法の必要性がある。]
[0009] 従来のシステムの前述その他の、例示の問題、欠点および不利な点からみて、本発明の特徴は周期的なポーリングを使用せずにオペレーティング・システムの健全性をモニタリングする方法を提供することにある。]
[0010] 本発明の他の実施例の特徴は、特化されたモニタリングＡＰＩを用いずにＯＳモニタリングを提供することにある。]
[0011] 従って、本発明の例示の目的は、ポーリングを必要としない、効率的で柔軟性のあるイベント通知機構を提供することである。]
課題を解決するための手段

[0012] 本発明の他の例示の目的は、標準的なファイルシステムＡＰＩを使用し、かつ新しい追加的なセットの特化されたＡＰＩを導入することのない、広範なアプリケーションにより使用され得るイベント通知機構を提供することである。]
[0013] 前述の例示の特徴および目的を達成するために、本発明の第１の実施例の側面では、中央処理装置（ＣＰＵ）と、そのＣＰＵにより実行されるオペレーティング・システム（ＯＳ）中のイベント通知機構のための命令を含むメモリとを含む装置であって、前記ＯＳのイベント通知機構は、イベントの通知のための登録をするステップ、各イベントが生じるときにイベント通知を受け取るステップ、および生じたイベントの詳細を得るステップのうちの１つもしくは複数をイベント・コンシューマが使用するための標準ファイルシステム・インターフェースを含む装置がここで説明される。]
[0014] 本発明の第２の実施例の側面では、オペレーティング・システム二イベントを通知する方法であって、標準である１個もしくは複数個のファイルシステム・インターフェースを含み、イベントの通知のための登録をするステップ、登録されたイベントが生じるときイベント通知を受け取るステップ、および生じたイベントの詳細を得るステップのうちの一つもしくは複数のステップをイベント・コンシューマが使用するために標準ファイルシステム・インターフェースを提供することを含む方法がここで説明される。]
[0015] 本発明の第３の実施例の側面では、オペレーティング・システムにイベントを通知する前述の方法を行うためにディジタル処理装置により実行可能なマシーン可読命令のプログラムを実体的に含むマシーン可読媒体がここで説明される。]
[0016] 本発明の第４の実施例の側面では、前述の方法によりオペレーティング・システムにイベントを通知する方法を含む、オペレーティング・システムを動作させる第１のコンピュータと、前記イベント通知を受け取る第２のコンピュータとを含むネットワークがここで説明される。]
[0017] 本発明の第５の実施例の側面では、コンピュータのオペレーティング・システムの健全性をモニタリングするステップと、前記コンピュータの問題をデバッギングするステップと、前記オペレーティング・システムにより実行されるプログラムまたは前記オペレーティング・システムのためのソフトウエア・ソリューションの開発をするステップとのうちの少なくとも一つを含むサービスであって、前記のモニタリング、前記のデバッギングもしくは前記の開発が、前述の方法に基づき前記通知機構を用いる前記オペレーティング・システムのイベント通知を受け取るステップを含む前記サービスがここで説明される。]
[0018] 以下の記述から明らかになるように、本発明は、現存するソフトウエアよりもはるかに有用な情報を提供し、かつファイルシステム・インターフェース（例えば、open（）、write（）、select（）、read（）、close（）、・・・）をサポートする任意のモニタリング・ソフトウエアにより直接使用可能なものを含む、多くの効果を提供する。それはまた時間に厳しいイベントをもっと効果的にモニタし、その結果そのシステムが破滅する前に迅速な応答アクションがとられる。]
[0019] 本発明はまた、全てのユーザーによる定期的なポーリングの代わりに、select（）コール通知を用いることによって低いオーバーヘッドを達成するとともに、フレキシビリティを提供する。何故ならば複数のコンシューマが、夫々は異なる閾値を備えている同じイベントを、ＯＳ上のオーバーヘッドをリニアに増加させずに、モニタすることができるからである。更に、複数のアプリケーションがソフトウエア開発者へのもっと高度なデバッギング機能を提供するためのデバッギング・ツールの中に統合することを含め、本発明から利益を受ける。]
[0020] 前述その他の例示の目的、側面および効果が、本発明の実施例の、図面に関連した以下の詳細な記述から理解できよう。]
図面の簡単な説明

[0021] 本発明が適用可能な一般的なオペレーティング・システムの種々のコンポーネントの実施例の説明図である。
本発明の一実施例におけるイベント管理ファイルシステム２００の主要なコンポーネントをリストした図である。
本発明のイベント管理ファイルシステムがどのようにしてそれ自体をエンド・ユーザーに提供するかを示す実施例の説明図である。
イベント管理ファイルシステムが装着されるときに生じるアクションの手順を示す実施例のフローチャート４００を示す。
イベント・コンシューマがイベント管理ファイルシステムでもってイベントを知らせられるために登録するとき、生じるアクションの手順の典型的なフローチャート５００を例示する。
或るイベントがイベント・プロデューサのところで生じるとき行われるアクションの手順の実施例のフローチャート６００を示す。
イベント・コンシューマが異常な終了をするときに行われるアクションの手順の実施例のフローチャート７００を示す。
本発明をその中に実装するための実施例のハードウエアおよび情報処理システム８００を示す。
本発明による方法のプログラムのステップをストアするための信号担持媒体９００（例えば、ストレージ媒体）を示す。
本発明の概念を実装するのに使用され得るソフトウエア・モジュールの実施例のブロック図を示す。]
実施例

[0022] ここで図面、特に図１ないし図１０を参照すると、本発明による方法および構成の実施例がこれから説明する。] 図１ 図１０
[0023] 前述のとおり、この開示は、ポーリングの必要性なしに、かつ新規の特化されたＡＰＩを生じる必要性なしに、ＯＳイベントをモニタし、そしてそれらの登録されたイベントが発生する際に非同期にユーザーに通知するための新規の、効率的、かつフレキシブルな機構およびインフラを記述する。この機構は今日優位のシステム管理言語、例えばＰｅｒｌ、ＰＨＰ、Ｐｙｔｈｏｎ、Ｊａｖａ、Ｃ、Ｃ＋＋等の内の任意のもので書かれるモニタリング・アプリケーションで使用される意図がある。]
[0024] 定期的なポーリングに関連する問題及び新しい特化されたＡＰＩを開発するのに関連する問題を除去するために、本発明は、ポーリングを必要とせず、新しい特化されたＡＰＩを生じる必要性もなしに、ＯＳイベントをモニタし、かつそれらの登録されたイベントの生じるときにユーザーに非同期に通知するための新規で、効率的、かつフレキシブルな機構およびインフラを記述する。この機構は先に挙げた優位のモニタリング言語のいずれかで書かれたモニタリング・アプリケーションで使用され得る。]
[0025] 具体的には、本発明の機構は、ファイルおよびファイルシステムをアクセスするのに使用される、ユビキタスおよび標準のファイルシステムＡＰＩ（例えば、open（）、write（）、select（）、read（）、close（）など）に例えば基づく。]
[0026] 標準的なファイルシステム・インターフェースがよく定義され、よく知られていることに留意されたい。例えば、それらはＩＢＭ、ＨＰおよびＳＵＮを含むメンバーを有するopen・ソース・グループ・コンソーシアムにより開発されたＰＯＳＩＸ．１仕様書（ＰＯＳＩＸはＰｏｒｔａｂｌｅ Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍｓ Ｉｎｔｅｒｆａｃｅを表す）の一部である。この仕様書はまたＩＥＥＥスタンダード１００３．１としても良く知られている。但し、このスタンダードがただのファイルシステム関連サービスというだけでなくもっと多くのオペレーティング・システムのサービスをカバーすることに留意されたい。人はこのスタンダードを「シングル・ユニックス仕様書」ウェブサイトのところで見ることができる。]
[0027] しかし、本発明はこの一つのオペレーティング・システム仕様書やここに記される実施例に限定するような意図がないことにも留意されたい。むしろ、それは「標準ファイルシステム・インターフェース」という用語が、ＯＳモニタリングのために特別に開発された特化されたインターフェースに頼ることなく、そのオペレーティング・システム環境で一般に利用できるファイルシステム・インターフェースのことをいうように意図している。]
[0028] より詳しく言うと、本発明は、モニタリング・アプリケーションにより使用されるザ／ａｈａファイルシステム（縮めてＡＨＡＦＳ）とここでは呼ばれるが、ファイルシステム（ＦＳ）を含む。ＡＨＡＦＳはＡｕｔｏｎｏｍｉｃ Ｈｅａｌｔｈ Ａｄｖｉｓｏｒ ＦｉｌｅＳｙｓｔｅｍの略語である。]
[0029] このファイルシステムはルート・ディレクトリ／ａｈａ（例えば、図２参照）の下で、ここでは「モニタ・ファクトリ・ディレクトリーズ」と呼ばれる特別のディレクトリとしてオペレーティング・システム（ＯＳ）中に種々のシステム・イベント・プロデューサを提供する。このイベント・プロデューサにより扱われる個々のイベント・インスタンスは、ここで「モニタ・ノード」と呼ばれるリーフ・レベルのファイル・ノードとして提供される。各モニタ・ノードは一つのそして唯一のモニタ・ファクトリ・ノードの下にあるであろう。] 図２
[0030] 以下の手順のアクションはイベントの通知がどのようにして生じるかを高レベルで例示的に示す。]
[0031] １．モニタリング・アプリケーションはあるイベントに関連付けられたモニタリング・ファイルをまず生成し開くことによってそのイベントが通知されるよう登録する。その所望のモニタ・ファイルが既に存在するならそれを生成する必要がないことに留意されたい。]
[0032] ２．そこでそのモニタリング・アプリケーションは、そのファイルの中に、そのイベントがトリガされるべきときを示すための幾つかのイベント・プロデューサ特有入力情報を書き込む。]
[0033] ３．そのモニタリング・アプリケーションは、起こるべきイベントを体躯するためにselect（）をコールする。]
[0034] ４．ＡＨＡＦＳがそのモニタリング・アプリケーションのイベント・リクエストをそのイベント・プロデューサに進める。]
[0035] ５．そのイベントが生じるときに、そのイベント・プロデューサはそのイベントの詳細についてＡＨＡＦＳを知らせる。]
[0036] ６．ＡＨＡＦＳが、select（）コールにおいて待機しているアプリケーションまたはモニタリング・アプリケーションを起こす。]
[0037] ７．モニタリング・アプリケーションがそのイベントの詳細を得るためにそのモニタリング・ファイルから読み出す。]
[0038] ８．モニタリング・アプリケーションが最早通知されることを必要としなくなると、それはそのファイルを閉じる。]
[0039] 前述のステップおよび実施例の適用可能な環境を以下でもっと詳しく説明する。]
[0040] 実施例の典型的なオペレーティング・システム（ＯＳ）の主要なコンポーネントが図１の概略１００に示されている。ＯＳインスタンスがユーザー・モードで実行する幾つかのアプリケーション１０１・・・１０９を普通は含む。カーネル１１０がＯＳのコアを含む。カーネルそれ自体はプロセスおよびスレッドのスケジューラ１１１、バーチャル・メモリ・マネジャ（ＶＭＭ）１１２、Ｉ／Ｏサブシステム１１３、論理ファイルシステム（ＬＦＳ）層１４、複数のフィジカル・ファイルシステム（ＰＦＳ）１１５、１１６、ネットワーキング・サブシステム１１７など、複数のサブコンポーネントよりなる。 アプリケーション１０１・・・１０９は一組のインターフェース呼び出しのシステム・コール１３０を介してカーネルにより提供されるサービスをアクセスする。] 図１
[0041] これらのシステム・コールは、ユーザー・モード（低い特権レベル）からカーネル・モード（高い特権レベル）にアプリケーションの特権レベルを、それらがカーネルにより提供されるサービスを実行するときに、変える。このＦＳのシステム・コールはＬＦＳ層１１４により提供される一組のシステム・コールである。ＦＳシステム・コールの例は、open（）、close（）、read（）、write（）、select（）、シーク（）等である。これらのＦＳシステム・コールは当業者に周知であることを理解されたい。]
[0042] 本発明では、アプリケーションがファイル上でＦＳシステム・コールを発するとき、ＬＦＳ層がそのファイルに対応するフィジカル・ファイルシステム（ＰＦＳ）を識別し、そのＰＦＳ上で動作を引き起こす。その動作はそのコールされた仮想ノード（ｖｎｏｄｅ）動作およびバーチャル・ファイルシステム（ＶＦＳ）動作によって提供される。]
[0043] 「ｖｎｏｄｅ動作」および「ｖｆｓ動作」という用語がＵｎｉｘオペレーティング・システムにおける標準ファイルシステムの一部であることに留意されたい。このコンテキストにおいて「バーチャル」という用語は、そのフィジカル・ファイルシステムをアクセスしているアプリケーションとそのフィジカル・ファイルシステムを提供するカーネル／カーネル・エクステンションとの間に或るレベルの不正な手段（indirection）があることを暗示する。本発明はＵｎｉｘなどの上に実装されるように、任意の他のファイルシステムもまたｖｎｏｄｅおよびｖｆｓ動作を介してアクセスされるであろう。図２に示されるように、本発明（ＡＨＡＦＳ）はＰＦＳのようなオペレーティング・システムに現れ、それ自体をファイル・ツリーとしてモニタリング・アプリケーションに提供する。] 図２
[0044] 図２はＡＨＡＦＳフレームワークがどのようにしてエンド・ユーザーおよびモニタリング・アプリケーションに現れるかを示す。この実施例２００では、この技法がルート・ノード／ａｈａ２０１でもって始まるファイル・ツリーにより提供される。そのルート・ディレクトリの下に幾つかのサブディレクトリ２１０、２１１、２１２・・・があり、これらはここで「モニタ・ファクトリ」ノードまたはサブディレクトリと称され、夫々一つのイベント・プロデューサを代表する。] 図２
[0045] この例示の実装例はフレキシブルであり、そして／ａｈａディレクトリとモニタ・ファクトリ・ノードとの間に幾つかの中間的なサブディレクトリが生成されるのを許容することによって、改良された組織またはハウスキーピングを可能にする。各モニタ・ファクトリ・ノードの下方に、１個または複数個のモニタ・ノードがあり得る。各モニタ・ノードはイベント・プロデューサによりモニタされ得るユニークなイベントを表し、それがコンシューマの通知を送ることができる。]
[0046] 図２は、ｕｔｉｌＦｓ．ｍｏｎＦａｃｔｏｒｙ２１０、 ｍｏｄＦｉｌｅ．ｍｏｎＦａｃｔｏｒｙ２１１、およびｗａｉｔＴｍＣＰＵ．ｍｏｎＦａｃｔｏｒｙ２１２という３つのモニタ・ファクトリを備える例を示す。各モニタ・ファクトリ（例えば、２１０、２１１、２１２）は１個もしくは複数個のモニタ・ノードを有し、夫々のノードが、生じるべきイベントのためにそれがモニタするオブジェクトである。これらのモニタ・ノードは、あるイベントのことを通知されるようそれが登録するときそのユーザ・アプリケーションにより生成される。] 図２
[0047] 図２は、ｖａｒ．ｍｏｎ２２１、ｔｍｐ．ｍｏｎ２２２、ａｂｃ．ｍｏｎ２３１、ｐａｓｓｗｄ．ｍｏｎ２３２、およびｗａｉｔＴｍＣＰＵ．ｍｏｎ２２５という５個のモニタ・ノードを示す。この実施例では、そのモニタ・ファクトリがサブディレクトリ・ノードとして示され、そしてそのモニタがこれらのサブディレクトリの下でファイルまたはファイル・ノードとして示される。そのファイル名のエクステンション．ｍｏｎ、およびディレクトリ名のエクステンション．ｍｏｎＦａｃｔｏｒｙは、使用するのにここではサンプルの表記法（convention）として与えられるが、他の表記法も使用され得る。] 図２
[0048] 図３は、図１で説明した典型的なオペレーティング・システムにおいてＡＨＡＦＳ疑似ファイルシステムを実装した実施例であるが、そのＯＳの特定の構造に依存しないファイルシステムを介してイベント通知を得る実施例を示す。] 図１ 図３
[0049] 図３を参照すると、ＡＨＡＦＳフレームワーク３００がＯＳのユーザー層３０５およびカーネル層３０６の両方にまたがる。ユーザー層３０５では、１個もしくは複数個のシステム管理／システム・モニタリング・アプリケーション３０１、３０２・・・等がユーザー空間３３３中にある。カーネル層３０６中では、ＡＨＡＦＳがカーネル３３５の内部かまたはカーネル機能拡張すなわちカーネル・エクステンション３３５として実装され得る。「カーネル・エクステンション」という用語は、本発明の実施例が実装されてきた、ＵＮＩＸオペレーティング・システムであるＡＩＸに特有に用語であることに留意されたい。他のオペレーティング・システムは、類似の概念に対し異なる用語を有しているかもしれない。もちろん、本発明はここでの開示を全体として把握すれば当業者に理解されるように、ＵＮＩＸオペレーティング・システムまたはここで示される例示の用語に限定されない。図３に示す実施例では、ＡＨＡＦＳモジュール３３０がカーネル・エクステンション３３４に実装されるように示されている。この位置が生み出されたのはカーネル３３５をできるだけ小さく保持するための選択からであるが、ＡＨＡＦＳモジュール３３０がカーネル３３５の中に代わりに実装され得ないという理由があるわけではない。] 図３
[0050] イベント・プロデューサがカーネル３３５の種々のサブシステム、スケジューラ１１１、ＶＭＭ１１２、Ｉ／Ｏサブシステム１１３、論理ファイルシステム１１４等のいずれかにある。かくして、各サブシステムはゼロまたはそれより多くのイベント・プロデューサを含むことができる。現在の実施例に説明されていないが、イベント・プロデューサはまたカーネル・エクステンション３３４にあってもよい。カーネル・エクステンション３３４がイベント・プロデューサを含むときは、それが初期化されるときにカーネルにそのイベント・プロデューサの利用可能性を知らせる。]
[0051] ユーザー空間のモニタリング・アプリケーション３０１、３０２、・・・は、ＦＳ関連システム・コールすなわちシステム・コール・サービス３１０の形態で利用可能な標準ファイルシステム・インターフェース３３２を介してＡＨＦＡＳモジュール３３０と通信する。そのシステム・コール・サービス３１０は、次に仮想ノード（ｖｎｏｄｅ）オペレーション３１１および仮想ファイルシステム（ｖｆｓ）オペレーション３１２を介してＡＨＡＦＳサービスを呼び出す。サービスの呼び出しの手順および各ステージで呼び出される特定のサービスは後の図で与えられる。サービスの呼び出しの手順、および各ステージにおいて呼び出される特定のサービスを、実施例のフローチャートとして後の図で示し、以下の段落でもっと詳細に説明する。]
[0052] ＡＨＡＦＳモジュール３３０は、ＡＨＡＦＳモジュールを初期化する際、イベント・プロデューサごとに決定される別個の登録機能を用いてイベント・プロデューサと通信する。イベント・プロデューサは登録機能で与えられるコールバック機能を介してＡＨＡＦＳモジュールと通信する。ＡＨＡＦＳモジュールとイベント・プロデューサとの間で交換される情報の詳細は各イベント・プロデューサに特有である。]
[0053] 図４はＡＨＡＦＳが装着されるときに取るステップの手順４００を列挙する。その装着動作がＡＨＡＦＳモジュールを初期化する。ステップ４０１では、システム管理者が装着ポイントとして／ａｈａでもってその装着命令を呼び出す。その装着命令はステップ４０２でＡＨＡＦＳの装着サービスに、新しい装着動作がそのＡＨＡＦＳモジュールに対しリクエストされたことをステップ４０２で通知する。] 図４
[0054] ステップ４０３では、ＡＨＡＦＳのｖｍｏｕｎｔ（ｖｆｓ—ｍｏｕｎｔ）サービスがそのパラメータの正確さをチェックし、そのＡＨＡＦＳの初期化を実行する。この初期化はカーネルにおいてイベント・プロデューサを識別し、そのデータ構造のためにメモリを割り当て、そして幾つかのデータ構造において機能ポインタおよびフィールドをセットする。その装着動作が成功裡に完了すると、そのイベント・コンシューマが、イベント通知のための登録をするためにＡＨＡＦＳを使用することができる。]
[0055] 図５は、イベント・コンシューマがイベントの通知を得るために登録するとき取るアクションの手順５００を示す。前に説明したように、イベント・コンシューマはイベントのことを通知されるよう登録するためかつそのイベントの詳細を得るために標準のファイルシステム・インターフェースを使用する。] 図５
[0056] ステップ５０１では、モニタリング・アプリケーションが、イベントをその対応する．ｍｏｎファイル上でopen（）を発行することにより登録する。]
[0057] ステップ５０２では、ＯＳの論理ファイルシステム層がｖｎｏｄｅ動作インターフェースを介してopen・リクエストをＡＨＡＦＳに通知する。]
[0058] ステップ５０３では、ＡＨＡＦＳがそのファイルをもしそれが既に存在していなければ生成し、その参照カウントを増加する。]
[0059] ステップ５０４では、論理ファイルシステムのシステム・コールが、そのコンシューマ・アプリケーションへのそのopenされたファイルに対応するファイル記述子を戻す。]
[0060] ステップ５０５では、write（）システム・コールを用いそのファイル中にイベント特定値をイベント・コンシューマが書きこむ。この値は、イベントのタイプによって整数、浮動小数点、ストリングまたは組み合わせであり得る。]
[0061] ステップ５０６では、ＡＨＡＦＳが書き込みバッファの中身を得て、そのイベントのタイプに従った中身を解釈する。例えば、ファイルシステムの使用が閾値をクロスするときはいつでもそのことをイベント・コンシューマにそのイベントが通知する筈なら、その書き込みバッファ中の値は整数として解釈される。その書き込みバッファが一旦構文解析されると、ＡＨＡＦＳはその中身を内部データ構造中にストアする。ＡＨＡＦＳは、そのイベント・コンシューマがselect（）システム・コール行うまで、そのイベント・リクエストをイベント・プロデューサに渡さない。]
[0062] ステップ５０７では、イベント・コンシューマはそのイベントのモニタリングを開始するようＡＨＡＦＳに知らせるために以前のopen（）コールからそれが受け取ったファイル記述子でもってselect（）インターフェースをコールする。]
[0063] ステップ５０８では、ＡＨＡＦＳがselect（）コールを受け取り、そのイベント・リクエストを直ぐに進める（ステップ５０９）べきか、それともイベント通知リクエストのインベントリ中にそれを維持すべきかを決定する。ＡＨＡＦＳは、そのリクエストを、もしそれが他のコンシューマからのイベント・リクエストをイベント・プロデューサに既に送っているなら、すぐにそのリクエストを進めるようなことはしない。この実施例では、任意の所与の時点で、所与のイベント・インスタンスのためのせいぜい一つのイベント・リクエストをイベント・プロデューサが有する。]
[0064] ＡＨＡＦＳがイベント・プロデューサにイベント・リクエストを送るとき、それはそのイベント・リクエストとともにコールバック機能アドレスをも渡す。その結果そのイベントが起こるとき、イベント・プロデューサは、そのコールバック機能を呼び出すことによりＡＨＡＦＳを知らせることができる。幾つかのイベント・プロデューサは、そのイベントの条件がその戻り値を用い、既に合致したかＡＨＡＦＳに知らせることができる。もしそのイベント条件が既に合致していれば、そのイベント・コンシューマは通知される（ステップ５１１）。]
[0065] 図６は、或るイベントがイベント・プロデューサで起こるとき行われるアクションの手順６００を例示的に列挙する。ステップ６０１では、登録されたイベント条件が合致したことをイベント・プロデューサが識別する。] 図６
[0066] ステップ６０２では、そのイベントの詳細を、以前に提供されたコールバック機能を用いてＡＨＡＦＳに知らせる。]
[0067] ＡＨＡＦＳがそのイベントの詳細を受け取るとき、それはステップ６０３で通知される必要のあるイベント・コンシューマのリストを識別する。通知される必要のあるイベント・コンシューマが一つよりも多くあることに留意されたい。ＡＨＡＦＳはイベント・プロデューサに唯一のリクエストを進めそれ自体のキューにその残りのコンシューマを保持する。また、イベントのタイプによっては、或るイベントに対し登録してきたイベント・コンシューマの必ずしも全てが所与のイベントの発生のための通知を得る必要はない。]
[0068] 図示のように、もしイベント・プロデューサが ｕｔｉｌＦｓである（すなわちファイルシステムの使用がコンシューマ特定の閾値をクロスするときはいつでもイベントをトリガする）なら、かつ現在の利用が９０％であるなら、９０％に等しいかそれよりも大きい閾値に対し登録されてきたこれらのイベント・コンシューマのみに通知されるべきである。従って、イベント・プロデューサがコールバック機能を呼び出すとき、ＡＨＡＦＳはこのイベントの発生（９０％フル）の結果として通知される必要のある全てのコンシューマを識別するためにそのキューを検索する。その識別されたコンシューマごとに、ＡＨＡＦＳは、これらのコンシューマによる次のread（）動作がそれらにイベントの詳細を与えるようにそのデータ領域を用意する。]
[0069] ステップ６０４では、ＡＨＡＦＳがその識別されたイベント・コンシューマの夫々を通知する。]
[0070] ステップ６０５では、残りのイベント・コンシューマがあるか見るためにＡＨＡＦＳがそのキューをチェックし、もしあればＡＨＡＦＳがそのイベント・プロデューサのところにそのイベントを再登録する。]
[0071] イベント・コンシューマとＡＨＡＦＳとの間でファイルシステム・インターフェースを用いる他の利点は、イベント・コンシューマの異常終了の場合に、図７のフローチャート７００に例示するようにクリーンアップが容易であることである。] 図７
[0072] ステップ７０１に示すように、イベント・コンシューマが異常に終了するときそのＯＳはファイル記述子がcloseされる必要があることをステップ７０２に於いてclose（）ｖｎｏｄｅ動作を介してＡＨＡＦＳに通知する。]
[0073] ステップ７０３では、ＡＨＡＦＳがコンシューマ・プロセスを識別し、このコンシューマ・プロセスがイベント・プロデューサのところでイベント登録を有しているかチェックする。もしそれが有していれば、そしてもしこのプロセスがただ一つのイベント・コンシューマであれば、ＡＨＡＦＳはその登録をリコールする。]
[0074] もし現在のコンシューマがそのファイル識別子をcloseしてしまった後１個もしくは複数個の他のコンシューマがそのイベントのために登録されているなら、ＡＨＡＦＳはそのイベントを適当なパラメータとともにそのイベント・プロデューサでもって再登録する。]
[0075] ステップ７０４では、現在のコンシューマを除去した後このイベントのための残りのイベント・コンシューマがないなら、ＡＨＡＦＳはそのモニタ・ノードのために維持されているそれ自体のデータ領域を使えるようにする。]
[0076] これまでの記述をガイドラインと捉えると、本発明の実施例は、一組のイベントのイベント通知のための登録をするステップ、各イベントが生じるときにイベント通知を受け取るステップ、および生じたイベントの詳細を得るステップのうちの１つまたは複数をイベント・コンシューマが使用できる標準ファイルシステム・インターフェースを提供することによるオペレーティング・システムをモニタする方法を含む。このその実施例はまた図２に示すとおり、イベント通知に利用できるイベントのリストのファイル・ツリー表示を含むこともできる。この実施例はまたイベント・コンシューマからイベント・リクエストとるため疑似ファイルシステムを提供するステップおよびそれらをプロデューサに進めるステップ、そのイベント・プロデューサからイベント発生情報を受け取るステップ、およびそのイベント・コンシューマにこの情報を通知するステップをも含むこともできる。] 図２
[0077] 実施例は、イベントが生じるときに通知を得るためイベント・コンシューマから疑似ファイルシステムの登録機能およびコールバック機能を提供するステップを含むことができる。]
[0078] 図２のＵｎｉｘベースの例に示すように、そのイベント・プロシージャおよびイベント・インスタンスを明示的に識別するためにそのファイル・ツリー表示は所定の命名規則を含むことができ、そしてモニタリングに際しそれらが関心のある特定のイベント・インスタンスのファイル・パス名をイベント・コンシューマが識別するのを助けるためにそのツリー中の所定の特定ノードを含むことができる。その命名規則はディレクトリ名に所定の拡張を加えることによりイベント・プロシージャを識別することができ、またファイル名に所定の拡張を加えることによりイベント・インスタンスを識別することができる。] 図２
[0079] Ｕｎｉｘベースの例では、所定のディレクトリ名拡張は「．ｍｏｎＦａｃｔｏｒｙ」 であり、所定のファイル名拡張は「．ｍｏｎ」であるが、他の規則も使用することができよう。]
[0080] ある実施例では、標準ファイルシステム・インターフェースが、イベント・インスタンスに対応するモニタ・ノードへのハンドルを得るためのインターフェース、イベント・タイプに特有のイベント・トリガ基準を示すためのインターフェース、イベントが生じるまで待機するためのインターフェース、イベントが生じた後そのイベントに特有の詳細を読み取るためのインターフェース、そしてイベント・インスタンスに対応するモニタ・ノードへのハンドルをリリースするためのインターフェースのうちの１個もしくは複数個を含むことができよう。]
[0081] 例として、イベント・インスタンスに対応するモニタ・ノードへのハンドルを得るための、open（）インターフェースになり得るインターフェース、イベント・タイプに特有のイベント・トリガ基準を示すための、write（）インターフェースになり得るインターフェース、イベントが起きるまで待機するための、select（）インターフェースになり得るインターフェース、イベントが起きてしまった後そのイベントに特有の詳細を読みだすための、read（）インターフェースとなり得るインターフェース、そしてイベント・インスタンスに対応するモニタ・ノードへのハンドルをリリースするための、close（）インターフェースニナリエルインターフェースがある。]
[0082] そのシステムは例示的に上記で列挙したファイルシステム・インターフェースを用い例示的に実装されているが、このリストおよび例は無制限である。標準ファイルシステム・インターフェースの他の例は、例えば、select（）の代わりにポール（）、あるいはread（）／write（）の代わりにｉｏｃｔｌ（）を含んでもよく、同じ結果を得る。他のファイル・システム、ｉｎｔも使用できる。]
[0083] 疑似ファイルシステムはまた、複数のイベント・コンシューマからの複数のイベント・リクエストを、イベント・プロデューサへの一つのリクエストに集約する１個もしくは複数個の設備、イベント・コンシューマへの読み出しを提供するための機構、およびイベントをトリガさせるようにしたプログラムのスタック・トレースを提供するための機構をも含み得る。]
[0084] 実施例のハードウエア実装例]
[0085] 図８は、好ましくは少なくとも一つのプロセッサまたは中央処理装置（ＣＰＵ）８１１を備える、本発明による情報処理／コンピュータ・システムの典型的なハードウエア構成を示す。但し、本発明がオペレーティング・システムを有する任意のディジタル装置を指向しているので、本発明が実施例のアーキテクチャを有するコンピュータに限定されないことに留意されたい。他のタイプの装置は、オペレーティング・システムを使用するが、当業者には良く理解される、図８に示すような「コンピュータ」とは考えられないかもしれない、例えば電化製品、電話、娯楽端末などを含んでいてもよい。] 図８
[0086] 図８のＣＰＵ８１１は、システム・バス８１２を介してランダム・アクセス・メモリ（ＲＡＭ）８１４、読み出し専用メモリ（ＲＡＭ）８１６、入出力（Ｉ／Ｏ）アダプタ８１８（ディスク・ユニット８２１、およびバス８１２へのテープ・ドライブ８４０などの周辺装置用）、ユーザー・インターフェース・アダプタ８２２（キーボード８２４、マウス８２６、スピーカ８２８、マイクロフォン８３２および／もしくはバス８１２への他のユーザー・インターフェースを接続するためのもの）、情報処理システムをデータ処理ネットワーク、インターネット、イントラネット、パーソナル・エリア・ネットワーク（ＰＡＮ）などに接続するための通信アダプタ８３４、ならびにバス８１２をディスプレイ装置８３８および／もしくはプリンタ８３９（例えば、ディジタル・プリンタなど）に接続するためのディスプレイ・アダプタ８３６に接続される。] 図８
[0087] 前述のハードウエア／ソフトウエア環境に加えて、本発明の異なる側面は前述の方法を行うためのコンピュータで実施する方法を含む。 一例として、この方法は前述の特定の環境で実施され得る。]
[0088] このような方法は、マシーン可読命令のシーケンスを実行するために、ディジタル・データ処理装置による実施というように、例えばコンピュータを動作させることにより実施されてもよい。これらの命令はいろいろなタイプの信号担持媒体に備わっていてもよい。]
[0089] このように、本発明のこの側面は、本発明の方法を行うため、前述のＣＰＵ４１１およびハードウエアを実装するディジタル・データ処理プロセスにより実行可能なマシーン可読命令のプログラムを物理的に伴なう信号担持媒体を含むプログラム製品を指向する。]
[0090] この信号担持媒体は、高速アクセス・ストレージにより代表されるような、例えばＣＰＵ８１１中に含まれるＲＡＭ、を含んでもよい。代わりに、本発明は、ＣＰＵ８１１により直接もしくは間接にアクセス可能な、磁気データ・ストレージ・フロッピー・ディスク９００（図９）など、他の信号担持媒体に含まれていてもよい。] 図９
[0091] フロッピー・ディスク９００、コンピュータ／ＣＰＵ８１１あるいはどこか他のところに含まれるかどうかに関係なく、ＤＡＳＤストレージ（例えば、従来からある「ハード・ドライブ」またはＲＡＩＤアレイ）、磁気テープ、電子的な読み出し専用メモリ（例えば、ＲＯＭ、ＥＰＲＯＭ、もしくはＥＥＰＲＯＭ）および光ストレージ装置（例えば、ＣＤ−ＲＯＭ、ＷＯＲＭ、ＤＶＤ、ディジタル光テープなど）、紙の「パンチ」カード、またはディジタルもしくはアナログおよび通信リンクおよびワイヤレスによる伝送のためのストレージ装置を含む他の適当な信号担持媒体など、多様なマシーン呼び出し可能なデータ・ストレージ媒体または他のコンピュータ・プログラム製品上に命令がストアされてもよい。本発明の実施例では、マシーン可読命令がソフトウエア・オブジェクト・コードを含んでもよい。]
[0092] ソフトウエア実装例]
[0093] 図１０は前述のような本発明の方法を実装するのに使用され得るソフトウエア・モジュール１０００をブロック図形式で示す。] 図１０
[0094] 本発明のファイルシステムの部分はＯＳの中に予め実装されるかまたはＯＳが立ち上がった後にあとで加えられることができる。前述のとおり、今日、本発明はＩＢＭＡＩＸオペレーティング・システムにおけるカーネル・エクステンションとして実装されてきた。ＡＩＸにおけるカーネル・エクステンションは動的にロード可能なモジュールに類似している。本発明のイベント・プロデューサ部分はそのＯＳの中に組み込まれる必要がある。もしイベント・プロデューサが利用できないなら、そのアプリケーションにＯＳイベントを露出するためにファイルシステムを加えることは無益である。]
[0095] オリジナルの開発からＯＳの中にすでに実装されているのではないなら、本発明はそれを用いることになるＯＳごとに実装されなければならない。この時点で、ここまでの実施例の説明がカーネル・モード・イベント・プロデューサに限定されてきたが、特にオペレーティング・システムの当業者はこの実施例をユーザー空間で生じるモニタ・イベントにも容易に拡張することができることに留意されたい。従って、この実施例が本発明の範囲を制限するものとしては意図されていない。]
[0096] しかし、本発明はシステム管理者がインストールすることができるようにソフトウエア・パッケージとして頒布されることもできる。その結果、モニタリング・アプリケーションがそれをその後使用することができる。代わりに、本発明はデバッギング・ツールの中に実装することもでき、これによってもっと高度のデバッギング機能をソフトウエア開発者に提供する。]
[0097] 図１０はそのような管理者のソフトウエア・パッケージまたはデバッギング・ツールのための例示的なブロック図１０００を示す。コントローラ・モジュール１００１が、管理者のソフトウエア／デバッギング・ツールの役割を務めるアプリケーション・プログラムの主要なルーチンであり、他のサブルーチンを制御するのにも資する。グラフィカル・ユーザー・インターフェース・モジュール１００２が、命令およびパラメータ値をユーザーが入力するのを許容するとともに、ディスプレイのためにインターフェースを提供し、デバッギング・ツールのためのデバッギング・ディスプレイを含む。ＡＨＡＦＳモジュール３３０を装着し、イベント・プロデューサ３３１を識別し、イベントの関心を登録し、そして閾値、パラメータ等をセットするために図３に示される標準ファイルシステム・インターフェース３３２を使用する図４に示す装着プロセスを通じてユーザーをガイドするためのサブルーチンをイベント管理モジュール１００３が提供する。] 図１０ 図３ 図４
[0098] 図９に例示するソフトウエア・パッケージは、ＯＳ全体がストアされかつそのＯＳが本発明のモニタリング・システムをそこに予め実装してきたか、あるいは本発明が実装され得るような管理者ツールをソフトウエアが含むようなそんなソフトウエアを代表するものとして示されていることに留意されたい。 これはブロック図形式１０００で図１０に例示的に示すものに類似する。
サービスの側面] 図１０ 図９
[0099] 本発明の更に他の側面では、オペレーティング・システムのモニタリングかまたはそのオペレーティング・システムのトップに載っているアプリケーション・プログラムのデバッギング、あるいはオペレーティング・システムのモニタリングが開発ツールを提供するソフトウエアの開発をその方法が許すので、ビジネスでのコンポーネントとして本発明を使用するかまたは他のエンティティにサービスを提供する機会もある。制限のない実施例は、例えばネットワーク上のオペレーティング・システム・モニタリング・サービスを提供することを含み、前術のイベント通知を受け取ることによって、タイムリな態様で介在するポテンシャルを含む。
結び]
[0100] 以上の説明から、本発明（ＡＨＡＦＳ）の利益が数あることが明らかであろう。ＡＨＡＦＳの幾つかの例示的および制限しない利益は、以下を含む。]
[0101] １）有用な情報‐本発明は現在あるソフトウエアよりもはるかに有用な情報を提供することができる。なぜならばイベントが生じる正確な時点でＡＨＡＦＳが制御を獲得することができるからである。例えば、侵入検出の場合、或る侵入についての「誰が、何を、いつ」という情報を提供するほかに、ＡＨＡＦＳはまたファイル修正時またはカーネル調整可能な値変更時に機能‐コール‐スタックを与えることにより「いかに」という情報をも与える。]
[0102] ２）有用性‐ＡＨＡＦＳは、ファイルシステム・インターフェース（例えば、open（）、write（）、select（）、read（）、close（）、・・・）をサポートする任意のモニタリング・ソフトウエアにより直接に使用可能である。大抵のシステム・モニタリング・ソフトウエアが、Ｊａｖａ、Ｐｅｒｌ、Ｃ等の中で書かれるので、開発者はこれらのＡＨＡＦＳ、ＡＰＩを容易に使用することができる。ＡＨＡのためｎｏ新たなＡＰＩを避けることによって、本発明は種々のランタイム（例えば、ＪａｖａのためにＪＮＩを加えること、Ｐｅｒｌ、ＰＨＰ・・・のために他のインターフェースを加えること）を延長する必要性を回避した。従って、本発明は、言語やオペレーティング・システムの新規な公開ごとに、新しいＡＰＩを維持する必要性を回避した。]
[0103] ３）定期的なモニタリングよりもselect（）ファイルシステム・インターフェースを介してタイム・クリティカルなイベントがもっと効果的にモニタされ、その結果そのシステムが決定的なものとなってしまう前に迅速な応答アクションを取ることができる。例えば、いっぱいになる／ｖａｒ／ファイルシステムを手動でもしくはプログラム的に取り扱うことができる。その状況を迅速に取り扱わないことはシステムのハングアップに通常はつながる。]
[0104] ４）低いオーバーヘッドが、全てのユーザーによる定期的なポーリングの代わりに、select（）コール通知を用いることによって達成される。]
[0105] ５）フレキシビリティ‐複数のコンシューマが同じイベントであって異なる閾値を備えるイベントをＯＳ上でオーバーヘッドを増さずにモニタすることができる。]
[0106] ６）複数のアプリケーション‐更に、本発明から利益を得ることができる複数のアプリケーションがある。いろいろなシステム管理アプリケーション、ＡＩＸ Ｓｙｓｔｅｍ Ｐ Ｃｏｎｓｏｌｅ、ＩＢＭ Ｓｙｓｙｔｅｍｓ Ｄｉｒｅｃｔｏｒ、ＩＢＭ Ｔｉｖｏｌｉ Ｍｏｎｉｔｏｒ ＨＰ ＯｐｅｎＶｉｅｗＢＭＣＰａｔｒｏｌなどがある。この技法はまたソフトウエア開発者にもっと複雑なデバッギング機能を提供するためのデバッギング・ツールに統合されることもできる。]
[0107] 本発明を実施例に従って説明してきたが、本発明が特許請求の範囲の趣旨および範囲内で修正して実施され得ることを当業者は認識している。]
[0108] 更に、出願人の意図は、全ての特許請求の範囲の要素の等価物を、後で中間処理中に補正されるとしても、包含することにあると理解されたい。]

权利要求:

請求項1
中央処理装置（ＣＰＵ）と、前記ＣＰＵにより実行されるオペレーティング・システムにおけるイベント通知機構のための命令を含むメモリとを含む装置であって、前記オペレーティング・システム・イベント通知機構が、前記オペレーティング・システムのための標準である１個もしくは複数個のファイルシステム・インターフェースを含み、イベント通知のための登録をするステップ、登録されたイベントが生じるときイベント通知を受け取るステップ、および生じたイベントの詳細を得るステップのうちの一つもしくは複数のステップをイベント・コンシューマが使用する装置。
請求項2
前記オペレーティング・システム・イベント通知機構が前記イベント通知のために利用できるイベントのリストのファイル・ツリー表示を含む、請求項１に記載の装置。
請求項3
前記オペレーティンス・システム・イベント通知機構が更に疑似ファイルシステムを含み、イベント・コンシューマからイベント・リクエストを取り、前記イベント・リクエストをイベント・プロデューサに進めるステップと、前記イベント・プロデューサからイベント発生情報を受け取るステップと、前記イベント発生情報を１個もしくは複数個の前記イベント・コンシューマに通知するステップとを含む請求項２に記載の装置。
請求項4
前記オペレーティング・システム・イベント通知機構が登録機能と、イベントが生じるときに前記１個もしくは複数個のイベント・コンシューマが通知を得るためにイベント・プロデューサから前記疑似ファイルシステムへのコールバック機能とを更に含む請求項３に記載の装置。
請求項5
前記ファイル・ツリー表示が、イベント・プロデューサおよびイベント・インスタンスを明示的に識別するための命名規則と、イベント・コンシューマがモニタリングに関心を示している特定のイベント・インスタンスのファイル・パス名を前記イベント・コンシューマが識別するのを助けるノードとを含む請求項２に記載の装置。
請求項6
前記命名規則が、ディレクトリ名に「．ｍｏｎＦａｃｔｏｒｙ」拡張を加えることによりイベント・プロデューサを識別するステップと、ファイル名に「．ｍｏｎ」拡張を加えることによりイベント・インスタンスを識別するステップとを含む、請求項５に記載の装置。
請求項7
前記ファイルシステム・インターフェースが、イベント・インスタンスに対応するモニタ・ノードへのハンドルを得るための第１のインターフェースと、イベント・タイプに特有のイベント・トリガ基準を示すための第２のインターフェースと、イベントが生じるまで待機するための第３のインターフェースと、前記イベントが生じた後イベントの特定の詳細を読み出すための第４のインターフェースと、前記イベント・インスタンスに対応するモニタ・コードへのハンドルをリリースするための第５のインターフェースとのうちの１個もしくは複数個を含む、請求項１に記載の装置。
請求項8
前記疑似ファイルシステムが複数のイベント・コンシューマからの複数のイベント・リクエストをイベント・プロデューサへの一つのリクエストに集約するための設備と、前記イベント・コンシューマへの非破壊読み出しを提供する機構と、イベントがトリガさせられるプログラムのスタック・トレースを提供するための機構とのうちの１つもしくは複数を含む、請求項３に記載の装置。
請求項9
オペレーティング・システム二イベントを通知する方法であって、標準である１個もしくは複数個のファイルシステム・インターフェースを含み、イベント通知のための登録をするステップ、登録されたイベントが生じるときイベント通知を受け取るステップ、および生じたイベントの詳細を得るステップのうちの一つもしくは複数のステップをイベント・コンシューマが使用するために標準ファイルシステム・インターフェースを提供することを含む方法。
請求項10
イベント通知のために利用できるファイル・ツリー表示を提供するステップを更に含む、請求項９に記載の方法。
請求項11
イベント・コンシューマからイベント・リクエストを取り、前記イベント・リクエストをイベント・プロデューサに進めるステップと、前記イベント・プロデューサからイベント発生情報を受け取るステップと、前記イベント発生情報を１個もしくは複数個の前記イベント・コンシューマに通知するステップとのために疑似ファイルシステムを提供するステップを更に含む、請求項１０に記載の方法。
請求項12
登録機能と、イベントが生じるときに前記１個もしくは複数個のイベント・コンシューマが通知を得るためにイベント・プロデューサから前記疑似ファイルシステムへのコールバック機能とを更に提供する、請求項１１に記載の方法。
請求項13
前記ファイル・ツリー表示が、イベント・プロデューサおよびイベント・インスタンスを明示的に識別するための所定の命名規則と、イベント・コンシューマがモニタリングに関心を示している特定のイベント・インスタンスのファイル・パス名を前記イベント・コンシューマが識別するのを助けるため前記ツリー中の所定のノードとを含む、請求項１０に記載の方法。
請求項14
前記命名規則が、ディレクトリ名に所定の拡張を加えることによりイベント・プロデューサを識別するステップと、ファイル名に所定の拡張を加えることによりイベント・インスタンスを識別するステップとを含む、請求項１３に記載の方法。
請求項15
所定のディレクトリ名の拡張が「．ｍｏｎＦａｃｔｏｒｙ」を含み、前記所定のファイル名の拡張が「．ｍｏｎ」を含む、請求項１４に記載の方法。
請求項16
前記ファイルシステム・インターフェースが、イベント・インスタンスに対応するモニタ・ノードへのハンドルを得るためのインターフェースと、イベント・タイプに特有のイベント・トリガ基準を示すためのインターフェースと、イベントが生じるまで待機するためのインターフェースと、前記イベントが生じた後イベントの特定の詳細を読み出すためのインターフェースと、前記イベント・インスタンスに対応するモニタ・コードへのハンドルをリリースするためのインターフェースとのうちの１個もしくは複数個を含む、請求項９に記載の方法。
請求項17
前記イベント・インスタンスに対応するモニタ・ノードへのハンドルを得るためのインターフェースが、open（）インターフェースを含み、前記イベント・タイプに特有のイベント・トリガ基準を示すためのインターフェースがwrite（）インターフェースを含み、前記イベントが生じるまで待機するためのインターフェースが、select（）インターフェースを含み、前記イベントが生じた後イベントの特定の詳細を読み出すためのインターフェースが、read（）インターフェースを含み、前記イベント・インスタンスに対応するモニタ・コードへのハンドルをリリースするためのインターフェースが、close（）インターフェースを含む、請求項１６に記載の方法。
請求項18
前記疑似ファイルシステムが複数のイベント・コンシューマからの複数のイベント・リクエストをイベント・プロデューサへの一つのリクエストに集約するための設備と、前記イベント・コンシューマへの非破壊読み出しを提供する機構と、イベントがトリガさせられるプログラムのスタック・トレースを提供するための機構とのうちの１つもしくは複数を含む、請求項１１に記載の方法。
請求項19
前記オペレーティング・システムの健全性の表示、および前記オペレーティング・システムまたは前記オペレーティング・システムにより実行されるプログラムのためのデバッギング・プロシージャにおける表示のうちの少なくとも一つとしてイベント通知を提供するステップを更に含む、請求項９に記載の方法。
請求項20
前記オペレーティング・システム・システム上に前記標準ファイルシステム・インターフェースを装着するステップを更に含む、請求項９に記載の方法。
請求項21
前記標準ファイルシステム・インターフェースが前記オペレーティング・システムのＬｏｇｉｃａｌＦｉｌｅｓｙｓｔｅｍ（ＬＦＳ）層から引き出されている、請求項９に記載の方法。
請求項22
オペレーティング・システムにイベントを通知する方法を実行するためにディジタル処理装置により実行可能なマシーン可読命令のプログラムを実体的に含むマシーン可読媒体であって、前記方法が、イベント通知のための登録をするステップ、登録されたイベントが生じるときイベント通知を受け取るステップ、および生じたイベントの詳細を得るステップのうちの一つもしくは複数のステップをイベント・コンシューマが使用するために標準ファイルシステム・インターフェースを提供するステップを含む、マシーン可読媒体。
請求項23
オペレーティング・システムを有するディジタル処理装置中のメモリであって、前記メモリは前記オペレーティング・システムの前記ディジタル処理装置による実行に備えて前記オペレーティング・システムをストアしており、かつ前記オペレーティング・システムはその内部に前記方法を実装しているところの前記メモリと、前記オペレーティング・システムを有する前記ディジタル処理装置中のメモリであって、前記メモリは前記ディジタル処理装置が前記オペレーティング・システムを実行している際前記オペレーティング・システムをストアしており、かつ前記オペレーティング・システムはその内部に前記方法を実装しているところの前記メモリと、ネットワーク上のコンピュータにおけるメモリであって、前記メモリは前記ネットワークに接続された他のコンピュータに前記方法をダウンロードするために前記方法をストアしている前記メモリと、前記ディジタル処理装置上に、前記方法を含む前記メモリ装置の内容をアップロードするために前記ディジタル処理装置上に挿入されるメモリ装置を含むコンピュータ・プログラム製品のうちの一つを含む、請求項２２に記載のマシーン可読媒体。
請求項24
イベントのセットのイベント通知のための登録をするステップ、各イベントが生じるときイベント通知を受け取るステップ、および生じたイベントの詳細を得るステップのうちの一つもしくは複数のステップをイベント・コンシューマが使用するために標準ファイルシステム・インターフェースを提供することによりオペレーティング・システムにイベントを通知する方法を含むオペレーティング・システムを動作させる第１のコンピュータと、前記イベント通知を受け取る第２のコンピュータとを含むネットワーク。
請求項25
コンピュータのオペレーティング・システムの健全性をモニタリングするステップと、前記コンピュータの問題をデバッギングするステップと、前記オペレーティング・システムにより実行されるプログラムまたは前記オペレーティング・システムのためのソフトウエア・ソリューションの開発をするステップとのうちの少なくとも一つを含むサービスであって、イベントのセットのイベント通知のための登録をするステップ、各イベントが生じるときイベント通知を受け取るステップ、および生じたイベントの詳細を得るステップのうちの一つもしくは複数のステップをイベント・コンシューマが使用するために標準ファイルシステム・インターフェースを提供するのに基づき通知機構を用いる前記オペレーティング・システムのイベント通知を受け取ることを前記のモニタリング、前記のデバッギングもしくは前記の開発が含む、前記サービス。